Columbia Kermit/kermit.zip/newsgroups/misc.19990725-20000114/[e-mail] _Thu Oct 28 10:28:19 1999.msg

Internet Message Format | 2020-01-01 | 6KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id KAA29901
    for <[e-mail]>; Thu, 28 Oct 1999 10:28:18 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id KAA09467
    for [e-mail]; Thu, 28 Oct 1999 10:19:45 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: [e-mail] (Frank da Cruz)
Subject: Re: Input timings
Date: 28 Oct 1999 14:19:44 GMT
Organization: Columbia University
Message-ID: <7v9m20$97o$[e-mail]>
To: [e-mail]

In article <7v837l$5vv$[e-mail]>,
Clarence Dold  <[e-mail]> wrote:
: Michael Hamelin <[e-mail]> wrote:
: : In my case, we are using a VMS AXP running ckermit7.0 beta 10
: : connecting to another VMS machine. We log in, and then send DCL
: : commands. One of the DCL commands is to have the VAX decompress
: : (UNZIP) a file. If you do this on the machine manually..it runs
: : for 2-4 minutes and then gives you back a prompt.  It does send a
: : few lines of output back to the screen, but no $ that i know of or
:
: Hey!
: Do you have
:     input 600 $
: in your script?
: You can't do that ;-)
: You need to look for another character for the input character.
: This "input" is responding to the first character that comes in.
:
"input 600 $" is correct -- dollar-sign is a normal character to
Kermit.  The form of the INPUT command that waits for ANY character
is "input 600" (no character or string specified).  However, since
the "$" is so prevalent in VMS messages, perhaps (as suggested in the
manual) a better way to wait for the prompt would be:

  input 600 {13\10\$ }

"input 600 $" will, of course, succeed as soon as a dollar-sign comes
in, which could happen if there were any VMS prompts that hadn't
been read yet, or any of the messages from UNZIP contained dollar signs,
which we tend to find in VMS filespecs.

This thread has several independent lives; one here, others in direct
email, so nobody gets to see it all.  (So please when starting one of
these threads, post to the newsgroup or send email to the
kermit-support address, but not both, thanks.)

Anyway, this is a classic example of asking the wrong question.  The
real question is: "How do I use Kermit to send a file from A to B,
unzip it on B (which could take any amount of time at all), and then
go on to the next item in the list as soon as unzipping is finished?"
The answer would have been more like this:

 1. Make the connection from A to B (in this case both of them are
    VMS systems).

 2. Start Kermit on B and put it in server mode.

 3. Send it the ZIP file (Note: since both systems are VMS, so the two
    Kermits will go into "labeled" transfer mode automatically, thus
    making an image copy of the file with all RMS attributes preserved).

(Note: I am assuming that the file needed to be sent from A to B, and was
not on B already; this was unclear from the postings.  If this was not the
case then just skip step 3.)

 4. Give the command "remote host unzip <name-of-zip-file>".  Now here we
    have an innovation in C-Kermit 7.0 that you probably won't even notice
    unless you tried this in earlier versions.  The Unzip process takes a
    long time (you don't have to know how long, as you do with the INPUT
    method).  In previous versions, the Kermit client would time out when
    no response came from the server within a few seconds, and eventually
    would give up after too many timeouts.  The new version, however,
    sends "keepalives" while a REMOTE HOST command is executing to ensure
    the client doesn't lose patience, no matter how long the host command
    takes.

 5. Go on to the next item.  I believe you wanted to rename the original
    ZIP file?  So "remote rename <name-of-zip-file> <new-name>".

In other words, do the whole job in client/server mode.  As you can see,
there are advantages to doing it this way:

 1. No more synchronization problems.

 2. You can check each operation for success and failure in a
    straightforward manner.

The script (after logging in) would look something like this:

  output kermit -x\13        ; (or "lineout kermit -x" in 7.0)
  input 20 READY TO SERVE... ; wait for confirmation
  if fail <do-something-appropriate>
  send somefile.zip
  if fail <do-something-appropriate>
  remote host unzip somefile.zip
  if fail <do-something-appropriate>
  remote rename somefile.zip something_else.zip
  if fail <do-something-appropriate>
  etc etc

As to why "input 600 $" appears to terminate early, we still don't know,
but we can't reproduce it either -- it works fine on our local VMS system.

"input 600 $" should not terminate early (and does not, in our experience)
unless (a) it gets a dollar-sign, or (b) the connection is lost.  This was
checked on a VMS-to-VMS connection with C-Kermit 7.0 Beta.10, same as you
have:

  DKA0:[FDC] C-Kermit>def xx echo, echo \v(time), input 600 $, status, -
   echo \v(time), show var in
  DKA0:[FDC] C-Kermit>xx
   0:36:57
    FAILURE
   \v(inchar) =
   \v(incount) = 1
   \v(inmatch) =
   \v(instatus) = 1
   \v(intime) = 600778
   \v(inwait) = 600
  DKA0:[FDC] C-Kermit>

- Frank